| Author |
Thread Statistics | Show CCP posts - 8 post(s) |
Dyu Ha
   |
Posted - 2009.07.18 13:53:00 -
[1]
Edited by: Dyu Ha on 18/07/2009 13:54:12
Same problem here. Funny thing is, when running two instances of eve (same box of course) they lose connection independently - my mining alt has just shown itself as disconnected to my hauling toon ;). Tztz... please ccp, look into this, it's getting tedious.
|
Dyu Ha
|
Posted - 2009.07.18 15:24:00 -
[2]
Hrm... is this really a network issue?
ccp log server says:
2009.07.18 14:55:40:096Closing connection to 87.237.38.200:26000: {'reasonCode': None, 'reason': u'Die Zugriffsstelle wurde geschlossen', 'exception': error(10053, 'Software caused connection abort', 'IOCompletionWsaGetOverlappedResult failed with error 10053
[...]
2009.07.18 14:55:40:123Unhandled exception in tasklet <TaskletExt object at 6814d58, abps=1001, ctxt='<NO CONTEXT>^<bound method ShipUI.ClickSpeedBtn of <form.ShipUI instance at (snip)>>'>
[...]
2009.07.18 14:55:40:143In svc.gameui.OnDisconnect
2009.07.18 14:55:40:151Exefile SHUTDOWN connection lost
That was just after warping to a belt - arriving there no asteorids showed up and the ship was unresponsive (checked that by trying to speed up). 30 sec. later the client restarted itself. So what does a techie read from that? What was first, hen (disconnect) or egg (software error closing connection on client side)?
Btw, I don't believe in ping statistics to check on network troughput issues.
|
Dyu Ha
|
Posted - 2009.07.20 06:40:00 -
[3]
That 3724 is one of the first ideas support always comes up with - linked to the idea of traffic shaping as far as I understood. I'm sorry to say that this didn't do any good in my case (regardless of machine or os used) so I went back to 26000 as it's the official port.
|
Dyu Ha
|
Posted - 2009.07.21 16:20:00 -
[4]
That's what I received:
> Thank you for your bugreport - ID:82289 Title: Multiple Disconnects
> We are already aware of this problem, and have added your bugreport to the existing issue in our defect tracking system.
Well, it's in their tracking system for a while now, isn't it? Maybe it repeatedly fell prey to some internal load balancing ;). But ho, that's unfair. They'll get it right one day.
|
Dyu Ha
|
Posted - 2009.07.22 18:29:00 -
[5]
Seems I have found a temporary solution to my socket losing problem: Socket holders. I forged them from a umts pcie card. Not so comfortable, but...
indeed I do no longer experience any connection losses now, playing with eplus, a german mobile phone and umts service provider. It blocks tracing, so I can't tell what route my packets take now, but it works for my mac client as well as my windows clients.
So it's traffic shaping after all? Not necessarily with our national isps but at some transfer point or however these connections between different carriers are called. Maybe I'll find some proxy out there with appropriate routing - umts is only umts after all.
Fly safe!
|
Dyu Ha
|
Posted - 2009.07.23 06:22:00 -
[6]
Ok, what i referred to is something like this.
The whole issue here reminds me of something a lot of AoC players went through maybe one year ago. At that time connection losses where quite common. In the end they were traced back to some transfer points between two high level isps, but I don't remember the details. Anyway I got around that problem by tunneling to an anonymizing proxy that happened to use an other route to the AoC servers. Pure luck, I'd say  . Same thing now: eplus uses a different routing from t-com which is my isp for everything else but eve now.
Fly save!
|
Dyu Ha
|
Posted - 2009.07.23 16:21:00 -
[7]
Bah. Let's fleet up and mop up those buggers podding our tcp/ip packets... but uh, don't really know what gate they're camping at...  |
Dyu Ha
|
Posted - 2009.07.24 12:31:00 -
[8]
Yeah, but 1. they can tell only for their own network infrastructure - there's no such thing as door-to-door service in "the internet", literally speaking. And 2. they might even tell the truth as far as Nilram itself is concerned. But what about the gateway to highlevel isps? We don't know and won't be able to get hands on good data - that's something CCP could (should, will, is propably right now trying to) do.
The guys at CCP are the professionals - let's hope they do dedicate some of their efforts to our little problem, even if we are a small (but loud) minority 
|
Dyu Ha
|
Posted - 2009.07.28 08:50:00 -
[9]
*knockknock* Hello CCP, anybody in there? As this problem exists for half a year now... any kind of statement will be welcome; something like "we're all off, walking in stations" or "no priority, relevant for 0,1% of accounts only" would help (in deciding to drop my acconts for good).
|
Dyu Ha
|
Posted - 2009.07.30 19:02:00 -
[10]
That's good for you, sir. I too hoped the best but hey ;). At least I get roughly through 2.5 ice mining rotations before my client closes on me... nothing else to be done with the client as your most dangerous opponent.
|
Dyu Ha
|
Posted - 2009.08.01 08:27:00 -
[11]
Hm. Last evening I tried and logged network traffic to get a glimpse of what is behind this strange client behaviour. Fortunately i didn't have to wait very long till the problem arouse again ;). These are the last two packages my cocoaPacketAnalyzer showed before the client became unresponsive:
Id = 1042
Source = 87.237.38.200
Destination = 192.168.2.104
Captured Length = 178
Packet Length = 178
Protocol = TCP
Information = 26000 -> 49639 ([ACK, PUSH], Seq=78424510, Ack=3910588283, Win=64528)
Date Received = 2009-07-31 19:04:06 +0200
Time Delta = 540.8911139965057
Id = 1043
Source = 192.168.2.104
Destination = 87.237.38.200
Captured Length = 54
Packet Length = 54
Protocol = TCP
Information = 49639 -> 26000 ([ACK], Seq=3910588283, Ack=78424634, Win=65535)
Date Received = 2009-07-31 19:04:06 +0200
Time Delta = 540.8911759853363
That's pretty much the same pattern most of the earlyer transmissions look like. After this there's a pause of about 2 min before the client tries to connect to tranquility. Maybe that's simply the moment when I tried to start the survey scanner, thereby realizing the ship had went dead. The result simply is this:
Id = 1127
Source = 192.168.2.104
Destination = 87.237.38.200
Captured Length = 170
Packet Length = 170
Protocol = TCP
Information = 49639 -> 26000 ([ACK, PUSH], Seq=3910588283, Ack=78424798, Win=65535)
Date Received = 2009-07-31 19:06:47 +0200
Time Delta = 701.8676419258118
repeating a few times but there's no reaction of tranquility. After a while I tried to log off which seemed to work as normal this time, but the network protocol shows neither 87.237.38.200 nor 87.248.216.17 answering in this process. So, what does a network geek make from this?
|
Dyu Ha
|
Posted - 2009.08.02 17:21:00 -
[12]
Edited by: Dyu Ha on 02/08/2009 17:22:07
;9 - wanna have the preformatted standard answer in advance?
I tried wireshark today on my windows client. It looks exactly as it's with my mac os client: all is well till some moment tranquility becomes unresponsive. The client resends it's packets up to 10 times, then it stalls and restarts (or shows socket closed). Btw - why is the header checksum of all packets sent by the client set to 0x000?
192.168.2.13387.237.38.200TCP49238 > quake [ACK] Seq=1649 Ack=27681 Win=64280 Len=0
192.168.2.13387.237.38.200TCP49238 > quake [PSH, ACK] Seq=1649 Ack=27681 Win=64280 Len=124
649650.534240192.168.2.13387.237.38.200TCP[TCP Retransmission] 49238 > quake [PSH, ACK] Seq=1649 Ack=27681 Win=64280 Len=124
[repeating 8x]
192.168.2.13387.237.38.200TCP49238 > quake [RST, ACK] Seq=1773 Ack=27681 Win=0 Len=0 (Client restarts)
|
Dyu Ha
|
Posted - 2009.08.04 18:06:00 -
[13]
 Originally by: Corozan Aspinall
Can we get some kind of official statement re: what is being done about it?
this.
|
Dyu Ha
|
Posted - 2009.08.04 18:23:00 -
[14]
Guess ccp's sniping for msg nr 1111 to give us some enlightenment
|
Dyu Ha
|
Posted - 2009.08.06 22:02:00 -
[15]
Edited by: Dyu Ha on 06/08/2009 22:04:01
Originally by: Nerakus
I don't think you should have any problems or repercussions from doing either of these, as I didn't. Really hope this helps you guys out! Good luck!
Kudos - sorry to say that it didn't help with my windows client (xp32 or vista64). And as my mac client shows the same behaviour it would have been kind of a surprise to me had it worked. Hope you guys out there have more luck with it.
|
| |
|